前端路由模式

对于前端路由来说，路由的映射函数通常是进行一些 DOM 的显示和隐藏操作。这样，当访问不同的路径的时候，会显示不同的页面组件。前端路由主要有以下两种实现方案：

• Hash
• History

Hash 模式

早期的前端路由的实现就是基于 location.hash 来实现的。

hash原理：直接使用 JavaScript来对 loaction.hash 进行赋值，从而改变 URL，触发 hashchange 事件 History 模式 提供了 History API 来实现 URL 的变化。其中做最主要的 API 有以下两个：history.pushState() 和 history.repalceState()

在不进行刷新的情况下，操作浏览器的历史纪录。唯一不同的是，前者是新增一个历史记录，后者是直接替换当前的历史记录

前端工程师未来会被ai取代吗

总是被面试问这个问题，我想说校招的我哪有那么多经验去判断能不能被取代，我既没深入公司业务也不怎么用AI写代码（毕竟在学习阶段上来用AI写代码干嘛呢）。但是又没办法去不回答是个公司都要出这个问题还要看回答质量如何，而且我已经回答了好几个乱七八糟的答案技术面都过了此次挂二面。

GPT帮整理：

前端工程师不会被 AI 取代，但「大量低价值前端」一定会消失。

做懂「工程」的前端

AI 很会写代码，但极弱于工程决策：

• 项目结构怎么拆？
• 状态放哪里？Redux / Zustand / URL / Server？
• 组件怎么设计才能复用 3 年？
• 怎么避免后期技术债爆炸？

技术债不是因为代码写得不优雅，而是因为「变化没有被显式建模」

你以为不会变的东西，最后一定会变。

1. 把稳定的东西写成灵活 把一定会变的东西写死
2. 隐式约定太多
3. 抽象提前 or 抽象错误 用一个组件 cover 10 种场景

解决方法：

1. 用「变化轴」而不是「功能」拆模块 其实就是哪些容易变动放到一块去不容易变动的放一起
2. 把「不稳定的东西」显式包一层 立刻包一层，不要直连。
3. 宁愿“重复一点”，也不要“错误抽象” 其实是组件复用性的坏处 因为复用多处等于改多处
4. 状态来源不清晰
5. 每个模块必须有「逃生通道」 会被替换的可能性

懂「业务 & 产品」的前端

• 这个交互是不是用户真的需要？
• 这个 loading 会不会让用户焦虑？
• 为什么这里要“慢一点反而更好”？

高级前端 / 前端架构师

• 微前端 / Monorepo
• SSR / RSC / Edge
• 性能优化（LCP、CLS、INP）
• 跨端（Web + RN + Electron + 小程序）
• 可视化 / 编辑器 / 图形系统